Restoration of items from backups and verification of recoverability from backups has been a concern throughout the era of the personal computer and distributed client server systems. Users need an ability to restore individual application items from full image level backups, including, but not limited to, backups, snapshots, copies, and replicas. Some examples of data items that typically need to be restored include:
an individual mailbox or email message from an email server backup, such as, but not limited to, a backup of a MICROSOFT™ Exchange server;
an individual user from directory server backup, such as, but not limited to a MICROSOFT™ Active Directory backup;
an individual table, view, or other database object from a database server backup, such as, but not limited to a backup of a MICROSOFT™ SQL SERVER™, ORACLE™, SYBASE™, or MYSQL™ database server; and
an individual document from a content library, such as, but not limited to a backup of a MICROSOFT™ SharePoint server.
Conventional methods for restoration of application items require application item-level processing during backup. Thus, the data for item-level restorations is readily available with this approach. However, conventional item backup techniques have a number of drawbacks. First, they require backup agents running next on the application server. Second, they typically require the same data to be backed up twice (on both the image-level and the object-level). This results in slower backup performance and larger backup files which contain redundant data within them.
Other conventional backup solutions are based on reverse-engineering of a proprietary binary storage format and extracting the data directly from a file used by an application that stores the data. Some examples of such files include MICROSOFT™ Exchange MDB files and MICROSOFT™ Active Directory NTDS.DIT files. An example of such a solution is Kroll OnTrack. Before application item-level restoration can take place, the required files to be extracted from the image-level backup files. An example of such two-step approach is a bundle of Vizioncore VRANGER PRO™ (performing Exchange MDB file recovery from image-level backup file) and QUEST™ Recovery Manager for Exchange products (performing individual item recovery from the extracted Exchange MDB file using low level API).
This conventional item-level restoration technique has a number of drawbacks as well. It usually requires the necessary file to be restored from an image level backup to the object-level restore application, which requires additional time and system resources. Some conventional solutions also involves using the undocumented APIs or proprietary binary structure of the underlying files. This makes the restoration approach unreliable, because any application patch or modification resulting in changes of the binary storage structure will render the restoration solution inoperable.
Conventional solutions also imposes a high cost of developing and maintaining the solution because of a need to reverse-engineer internal undocumented APIs or the binary storage format and update the product as the storage format or APIs are adjusted by a vendor due to updates or patches.
Finally, conventional solutions do not guarantee recoverability of data. Backup administrators cannot know if the particular backup is good, restorable, and contains valid uncorrupted data—until they actually try to restore the data. Administrators have to take risks because traditional methods of backup recoverability verification do not provide reasonable means to test every produced backup.
Traditional methods for backup recoverability testing include manual procedures involving the complete restoration of image-level backup into an isolated environment. In order to conserve storage space, backup files are typically highly compressed and/or de-duplicated. For example, some commercially available backup tools, such as VEEAM™ Backup from Veeam Software International Ltd., provide mechanisms for deduplication and compression of image level backup files. Deduplication may be applied when backing up multiple virtual machines (VMs) that have similar data blocks within them.
With deduplication, identical disk blocks or blocks of free space are eliminated from a backup file, which decreases the size of the created image level backup file. However, while deduplication serves to decrease the size of backup files, it increases the amount of time needed to perform subsequent backup verification and restorations from the backup files, because the backup data is no longer stored in native format.
Another means for decreasing the backup size is compression. Again, while compression decreases the size of created backup files, it increases the duration for backup creation, verification, and restoration procedures.
In order to enhance security, backup files are also often encrypted. Thus, in an initial step, backup files may need to be extracted (i.e., decompressed) and/or decrypted completely back to the native format before their contents can be read. Then, in case with some applications (such as MICROSOFT™ Active Directory Domain Controller) the extracted data is copied over to an isolated test environment, so the production environment is not affected during the testing. If the tested service relies on more than one application to run, the steps are repeated for all other applications. Finally, all of the service dependencies are started, and testing is performed to ensure that the service is working normally and the data is not corrupted.
With conventional backup verification approaches, executing backup verification can be a time-consuming process due to involving decompressing, decrypting, extracting, and staging the full contents of an image level backup in a test environment before verification can commence. Traditional backup verification methods do not enable system administrators to quickly and thoroughly verify correct recoverability of an image level backup, instead typically relying on manual verification. Accordingly, what is needed is a system to enable administrators to quickly and accurately verify the recoverability of an image level backup.
Thus, traditional item backup restoration and verification solutions have a number of drawbacks. These traditional solutions typically require that the backup file to be verified or to be used for an item-level restoration be fully extracted first, which requires significant free disk space and time. For example, it may take hours to extract and copy a backup's contents to a test environment due to the large size of image level backups. This approach typically requires dedicated hardware and storage resources, such as an isolated test environment or computer lab, in order to conduct the testing of the restored data objects. Additionally, such backup restoration and testing requires a significant amount of manual operation and intervention from administrators, such as initiating restores, test environment configuration, and testing operation of restored applications and data objects. Due to all these factors, it is simply impractical to perform recoverability testing and disaster recovery exercises on more than a small scope of backups, and more often than a few times per year. This means that recovery of data from a majority of backups simply cannot be guaranteed. Similarly, performing an item-level restore may take too much time, as compared to the time it takes to perform a full computer restore.
Therefore, there is a need for an efficient low cost methods for recovering an item from an image level backup and for testing recoverability of image-level backups.